【レポート】音声認識スタートアップにおけるMLOpsを考える #AWSSummit

DA事業本部の春田です。

AWS Summit Online絶賛開催中！ということで、本記事では「CUS-45: 音声認識スタートアップにおける MLOps を考える」の内容についてまとめていきます。

セッション情報

• Hmcomm株式会社 第1R&Dセンター リードエンジニア 齋藤 翔太 氏

Hmcommではディープラーニングを用いた"音声認識処理、自然言語解析処理を用いたプラットフォーム"と"異音検知解析処理を用いたプラットフォーム"を提供しています。研究成果を素早くプロダクトに反映するためには、モデルをトレーニング・評価・デプロイするためのパイプラインが重要です。また、運用面を考慮し音声データをエッジデバイスで効率よく推論するためのモデル開発にも取り組んでいます。 本セッションでは、MLOpsという観点からHmcommがこれまで取り組んできた知見をご紹介します。

※セッション動画は以下リンク

アジェンダ

1. 異音検知プラットフォーム「FAST-D」の紹介
2. MLOpsの「理想と現実」
3. FAST-DでのMLOps課題と解決
4. 本セッションのまとめ

• Hmcomm
  • 音声認識スタートアップ
  • VISION: 音から価値を創出し、革新的サービスを提供することにより社会に貢献する
  • 社員数60名以上
• 複雑になりがちなMLOpsを、Hmcommプロダクト開発の事例を含めて紹介
• 用語の整理
  • 研究者、リサーチャ、データサイエンティスト、データアナリスト = リサーチャ
  • プログラマ、開発者、ソフトウェアエンジニア、オペレータ = ソフトウェアエンジニア

異音検知プラットフォーム「FAST-D」の紹介

• FAST-Dで実現させること
  • AI/MLにより異音を検知し、社会の課題を解決する
  • Hmcomm音声分析リサーチャの研究技術を詰め込んだシステム
• 畜産
  • 動物の鳴き声を基に、食の安全品質や生産性向上をはかる
• 機械モニタリング
  • 工場の機械の駆動音などから異常を検知して、故障や事故を防止する
• 警備・防犯
  • 悲鳴やガラスの破砕音を検知して、犯罪の拡大を防ぐ
• インフラ
  • 電車の継ぎ目音などの異常を検知して、乗り物の事故を防止する

• FAST-Dの使い方
  • ユーザーは学習用音声と異音のラベルを用意
  • データをFAST-Dのソフトウェアにインプット
  • データを基に学習モデルを生成
  • 学習モデルは指定したデバイスにデプロイ
  • 推論デバイスにはマイクがつながっている
    • 図では畜産の豚の鳴き声がマイクに入る
  • 異常を検知するとユーザーに通知

• FAST-D開発体制
  • リサーチャとソフトウェアエンジニア
  • それぞれ専門知識と、共通の知識（MLライブラリ・ML手法実装）

MLOpsの「理想と現実」

• 機械学習のワークロード
  • 参考:機械学習のワークフローってどうなっているの ? AWS の機械学習サービスをグラレコで解説 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

• 理想と現実
  • 理想: データセット量が豊富
    • 要求の30%しかデータセット量がない
    • データ作るにも時間とお金がかかる
    • 少量のデータセットで、優秀なモデル出来上がりを期待される
  • 理想: アノテーションが正確
    • アノテーション作業に制限時間がある
    • アノテーション作業疲れる
    • アノテーション出来るデータセットではない
  • 理想: リサーチャが学習モデルの開発と運用を実施する
    • ハイパーパラメータ変えたくなったので変えた
    • フレームワークは最新を採用したい
    • 運用より研究…

FAST-DでのMLOps課題と解決

1. 音声における機械学習の課題
   1. 音声データ容量が膨大
   2. 音声データから生成される学習用データ数が膨大
   3. 論文に対する試行が多い
   4. 研究がソフトウェア開発と並行する
   5. 集音時間に比例して増えるアノテーション

1.音声データ容量が膨大 & 2.音声データから生成される学習用データ数が膨大

• Amazon S3とS3 Glacierを使用
• 制限なしのストレージ
• 時系列データのため、一定期間後にS3標準からIAに移行するライフサイクルを設定
• ほぼ使わなくなったデータはS3 Glacierへ

3.論文に対する試行が多い & 4.究がソフトウェア開発と並行する

• アーキテクチャから対策
• WebフロントエンドとWebAPIをAmazon CloudFront経由で提供
• バッグエンドはAmazon ECSをメインとしたMicroservicesで構成
• Microservicesの実行順はAWS Step Functionsにて定義
• IoTデバイスに学習モデルを送り、推論を実行

• 学習が開始されるまで
  • ユーザーが学習音声とラベルをアップロード
  • データはMLで利用しやすいよう、複数のデータに変換する前処理
    • 特徴量の抽出
    • 音声チャネルの分割
    • バリデーションデータの作成
    • etc...
• → ML手法は進化するため、変更対応が必要

• ML手法の改良が加えられた時
  • Microservice単位で改良、もしくはバージョンを追加できる
    • バリデーションデータの作成と学習ジョブの間に、新しいサービスを追加するなど
    • バージョン管理によって、以前の手法と現在の手法で比較や並行運用が可能
• → 最新のML手法を取り入れやすくなった

• モデルの学習から各推論デバイスへのデプロイ
  • ラーニングサービスへ、前処理済みのデータや特徴量がインプット
  • 収録される対象や環境によって最適な手法になるよう、複数のモデルを生成
    • 次元数やアルゴリズムを組み合わせた数だけモデルを生成
  • 生成されたモデルは、推奨モデル決定サービスへインプット
  • 決定されたモデルは各推論デバイスを管理しているデバイスマネジメントサービスを経由し、各デバイスに配布
• 学習に必要なリソースはSageMakerで実現

5.集音時間に比例して増えるアノテーション

• ラベルレコメンデーション
• Amazon SageMaker Ground Truth
  • 画像・映像・テキストに対応
  • FAST-Dのラベルレコメンデーションにも適用したかったが、音声に関する情報が少なく、調査と実証に多くの時間がかかると判断
  • 魅力的なサービスではあるため、将来的には導入したい
• 独自開発で進めることに
  • 要素技術やツールを一から選定

まとめ

• MLOpsの課題と解決方法を、Hmcomm FAST-Dの開発事例を元に紹介
• AWSサービスを使うことによって、MLOpsの課題をいくつも解決することはできたものの、FAST-Dサービスの特性から、独自開発を選択した所もある
• 新規性が高く、またリサーチやビジネスの点からも改良をし続けられる体制を作ることができた